info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Changes to Mozilla’s release model: Aurora is going away, Nightly is the focus for localization
397 views
Skip to first unread message
![Francesco Lodolo [:flod]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXs0woEjV8IBRZaZsGBgw87TNzFgo_G2aPycSH6tCfbedeoye4=s40-c)
Francesco Lodolo [:flod]
Apr 14, 2017, 10:48:51 AM4/14/17
to Mozilla l10n Mailing List
Hi localizers,
A significant change is going to happen to Mozilla’s release model, and
is going to happen quickly, in just a few days.
The Aurora branch will be discontinued on April 18 (next Tuesday).
In the original plan for Rapid Release Cycle, Aurora was supposed to
represent a first stabilization channel, with a userbase about 10 times
the size of Nightly’s, providing an additional cycle of user feedback.
It was also chosen as the branch to focus localization activity on,
since only string changes explicitly allowed could land, giving
localizers time to work on translation and testing before their work
reached a larger audience with Beta and Release.
With significant improvements in stability and performance in the
Nightly channel we have determined that we tend to gain more time by
testing and localizing in Nightly and stabilizing in Beta. The increased
speed to market and resulting quality and stability in the Beta channel
is why Aurora is going to be discontinued on April 18 (next merge day,
exceptionally on Tuesday).
On April 18, code for Firefox 54 is moving from Aurora to Beta as usual,
while Firefox 55 will remain on Nightly for a second cycle in a row (a
total of 14 weeks). On next merge day, June 12, Firefox 55 will move
directly from Nightly to Beta.
Between April and June, Firefox on desktop will continue to receive
updates for critical security issues and the Aurora and Developer
Edition populations will be migrated to the Beta update channel. On
Android, Aurora users will be migrated to Nightly.
More details will be available in the official FAQs that will be
published early next week.
*Impact on the localization process*
On April 18 (Monday evening, European time) we’ll disable all the Aurora
projects on both Pontoon and Pootle, in order to minimize the risk of
losing data. Starting from April 19, right after merge day, you’ll need
to focus your localization on Nightly (https://wiki.mozilla.org/Nightly)
instead of Aurora. We will work to ensure that localization tools will
be ready shortly after merge day.
This means that you will see more string changes, more frequently. To
avoid the risk of exposing poor strings to localizers, we plan to
publish new strings only once or twice a week. If you’re working
directly on Mercurial, or you’re interested in the technical details,
see the FAQs linked at the end of this email.
The original plan was to have cross-channel[1] available by the time
Project Dawn was in place, but the unexpected schedule acceleration
won’t make that possible. We expect to have it implemented by the time
Firefox 56 is available on the Nightly channel, and that will allow
localizers to work on one repository for both Nightly and Beta.
One other consequence is that all the testers you currently have on
Aurora will move to Beta around the end of the month. Pascal Chevrel,
who's been working on increasing Nightly's population in the past
months, has offered his help in building out a testing population on
Nightly. Among other things, we plan to run messages in about:home to
invite users of localized builds to install Nightly, but you should plan
to reach out to your community nonetheless.
From April 19, all localizers should migrate to Nightly and start using
it for testing their work. We now have builds for all languages that
previously had Aurora builds.
You can download Firefox Nightly (for desktop) from here
https://www.mozilla.org/firefox/channel/desktop/#nightly
Firefox for Android Nightly (multilocale) is available here
https://www.mozilla.org/firefox/channel/android/#nightly
If this page is not available in your language, it means that
mozilla.org translation is behind and you should translate it as soon as
possible. Please check your webdashboard:
https://l10n.mozilla-community.org/webdashboard/
In the meantime, you can use this page to download your localized
Nightly build
https://www.mozilla.org/firefox/nightly/all/
We’ve started building a series of Frequently Asked Questions, the
document is available here:
https://github.com/mozilla-l10n/localizer-documentation/blob/master/misc/aurora_faqs.md
It currently covers the same topics explained in this email, in some
cases with a bit more details.
It’s going to be a live, constantly evolving document: if you have any
questions, please ask here and we’ll update it as needed with relevant
information.
Francesco
[1]
https://blog.mozilla.org/l10n/2016/06/17/mozlondon-localization-sessions/
A significant change is going to happen to Mozilla’s release model, and
is going to happen quickly, in just a few days.
The Aurora branch will be discontinued on April 18 (next Tuesday).
In the original plan for Rapid Release Cycle, Aurora was supposed to
represent a first stabilization channel, with a userbase about 10 times
the size of Nightly’s, providing an additional cycle of user feedback.
It was also chosen as the branch to focus localization activity on,
since only string changes explicitly allowed could land, giving
localizers time to work on translation and testing before their work
reached a larger audience with Beta and Release.
With significant improvements in stability and performance in the
Nightly channel we have determined that we tend to gain more time by
testing and localizing in Nightly and stabilizing in Beta. The increased
speed to market and resulting quality and stability in the Beta channel
is why Aurora is going to be discontinued on April 18 (next merge day,
exceptionally on Tuesday).
On April 18, code for Firefox 54 is moving from Aurora to Beta as usual,
while Firefox 55 will remain on Nightly for a second cycle in a row (a
total of 14 weeks). On next merge day, June 12, Firefox 55 will move
directly from Nightly to Beta.
Between April and June, Firefox on desktop will continue to receive
updates for critical security issues and the Aurora and Developer
Edition populations will be migrated to the Beta update channel. On
Android, Aurora users will be migrated to Nightly.
More details will be available in the official FAQs that will be
published early next week.
*Impact on the localization process*
On April 18 (Monday evening, European time) we’ll disable all the Aurora
projects on both Pontoon and Pootle, in order to minimize the risk of
losing data. Starting from April 19, right after merge day, you’ll need
to focus your localization on Nightly (https://wiki.mozilla.org/Nightly)
instead of Aurora. We will work to ensure that localization tools will
be ready shortly after merge day.
This means that you will see more string changes, more frequently. To
avoid the risk of exposing poor strings to localizers, we plan to
publish new strings only once or twice a week. If you’re working
directly on Mercurial, or you’re interested in the technical details,
see the FAQs linked at the end of this email.
The original plan was to have cross-channel[1] available by the time
Project Dawn was in place, but the unexpected schedule acceleration
won’t make that possible. We expect to have it implemented by the time
Firefox 56 is available on the Nightly channel, and that will allow
localizers to work on one repository for both Nightly and Beta.
One other consequence is that all the testers you currently have on
Aurora will move to Beta around the end of the month. Pascal Chevrel,
who's been working on increasing Nightly's population in the past
months, has offered his help in building out a testing population on
Nightly. Among other things, we plan to run messages in about:home to
invite users of localized builds to install Nightly, but you should plan
to reach out to your community nonetheless.
From April 19, all localizers should migrate to Nightly and start using
it for testing their work. We now have builds for all languages that
previously had Aurora builds.
You can download Firefox Nightly (for desktop) from here
https://www.mozilla.org/firefox/channel/desktop/#nightly
Firefox for Android Nightly (multilocale) is available here
https://www.mozilla.org/firefox/channel/android/#nightly
If this page is not available in your language, it means that
mozilla.org translation is behind and you should translate it as soon as
possible. Please check your webdashboard:
https://l10n.mozilla-community.org/webdashboard/
In the meantime, you can use this page to download your localized
Nightly build
https://www.mozilla.org/firefox/nightly/all/
We’ve started building a series of Frequently Asked Questions, the
document is available here:
https://github.com/mozilla-l10n/localizer-documentation/blob/master/misc/aurora_faqs.md
It currently covers the same topics explained in this email, in some
cases with a bit more details.
It’s going to be a live, constantly evolving document: if you have any
questions, please ask here and we’ll update it as needed with relevant
information.
Francesco
[1]
https://blog.mozilla.org/l10n/2016/06/17/mozlondon-localization-sessions/
Francesco Lodolo [:flod]
Apr 14, 2017, 11:14:14 AM4/14/17
to Mozilla l10n Mailing List
> On April 18 (Monday evening, European time) we’ll disable all the
> Aurora projects on both Pontoon and Pootle
Michael Wolf
Apr 14, 2017, 12:18:39 PM4/14/17
to
Francesco Lodolo [:flod] schrieb:
a lot of text and all happens pretty suddenly. Aurora will be disabled
on Pontoon and Pootle? They all are Aurora! At least, until now.
Michael
>
>> On April 18 (Monday evening, European time) we’ll disable all the
>> Aurora projects on both Pontoon and Pootle
> Correction: April 17 (still Monday evening, European time).
>
Ji Francesco,
>> On April 18 (Monday evening, European time) we’ll disable all the
>> Aurora projects on both Pontoon and Pootle
> Correction: April 17 (still Monday evening, European time).
>
a lot of text and all happens pretty suddenly. Aurora will be disabled
on Pontoon and Pootle? They all are Aurora! At least, until now.
Michael
Jeff Beatty
Apr 14, 2017, 12:24:17 PM4/14/17
to Michael Wolf, dev-l10n
True, currently they are all Aurora. We will be moving the localization
process to Nightly until such a time as we can complete the work
surrounding cross-channel (one Firefox project, not channel-based Firefox
projects). The take away is that you may see new strings more often, but
you are expected to continue to localize at whatever pace/cadence you feel
most comfortable with.
Hope that helps,
Jeff
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
--
Thanks,
Jeff
process to Nightly until such a time as we can complete the work
surrounding cross-channel (one Firefox project, not channel-based Firefox
projects). The take away is that you may see new strings more often, but
you are expected to continue to localize at whatever pace/cadence you feel
most comfortable with.
Hope that helps,
Jeff
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
--
Thanks,
Jeff
Michal Stanke
Apr 14, 2017, 12:46:57 PM4/14/17
to dev-...@lists.mozilla.org
Hi Jeff.
I have been watching project Dawn for some time as well as the cross
channel l10n repository plan and I do not see anything bad about them.
But there are two things I wanted to clarify about the single repository
for both beta and nightly.
1. What tools are we going to use to find out, which strings belong to
beta and need to be done in the cycle?
2. What about sign-offs in case we change a string, that is used in
beta? Are we eventually dropping localizer sign-offs for beta too
and you (l10n-drivers) will take care of them as in aurora today?
Cheers,
Michal Stanke
Dne 14.4.2017 v 18:24 Jeff Beatty napsal(a):
I have been watching project Dawn for some time as well as the cross
channel l10n repository plan and I do not see anything bad about them.
But there are two things I wanted to clarify about the single repository
for both beta and nightly.
1. What tools are we going to use to find out, which strings belong to
beta and need to be done in the cycle?
2. What about sign-offs in case we change a string, that is used in
beta? Are we eventually dropping localizer sign-offs for beta too
and you (l10n-drivers) will take care of them as in aurora today?
Cheers,
Michal Stanke
Dne 14.4.2017 v 18:24 Jeff Beatty napsal(a):
> True, currently they are all Aurora. We will be moving the localization
> process to Nightly until such a time as we can complete the work
> surrounding cross-channel (one Firefox project, not channel-based Firefox
> projects). The take away is that you may see new strings more often, but
> you are expected to continue to localize at whatever pace/cadence you feel
> most comfortable with.
>
> Hope that helps,
> Jeff
>
> On Fri, Apr 14, 2017 at 10:18 AM, Michael Wolf <mil...@sorbzilla.de> wrote:
>
> process to Nightly until such a time as we can complete the work
> surrounding cross-channel (one Firefox project, not channel-based Firefox
> projects). The take away is that you may see new strings more often, but
> you are expected to continue to localize at whatever pace/cadence you feel
> most comfortable with.
>
> Hope that helps,
> Jeff
>
> On Fri, Apr 14, 2017 at 10:18 AM, Michael Wolf <mil...@sorbzilla.de> wrote:
>
Jeff Beatty
Apr 14, 2017, 12:52:38 PM4/14/17
to Michal Stanke, dev-l10n
Great questions! I'll do my best to answer and look to Pike to fill in
other gaps.
On Fri, Apr 14, 2017 at 10:46 AM, Michal Stanke <mst...@mozilla.cz> wrote:
> Hi Jeff.
>
> I have been watching project Dawn for some time as well as the cross
> channel l10n repository plan and I do not see anything bad about them. But
> there are two things I wanted to clarify about the single repository for
> both beta and nightly.
>
> 1. What tools are we going to use to find out, which strings belong to
> beta and need to be done in the cycle?
>
If you're using Pontoon or Pootle, all strings across branches will be in
one project. The repository will mark which strings belong to which version
and the tools will include that data.
As to what needs to be done within the cycle, one of the great things about
cross-channel is that there is less pressure on getting things done within
the cycle, since all strings across all branches will be in the same
repo/project.
> 2. What about sign-offs in case we change a string, that is used in
> beta? Are we eventually dropping localizer sign-offs for beta too
> and you (l10n-drivers) will take care of them as in aurora today?
>
Localizer sign-offs for all products have been dropped since June 2016.
We've taken over that process with the policy that we ship all good
updates, big or small, whenever they come in.
Thanks,
Jeff
>
>
> Cheers,
> Michal Stanke
>
> Dne 14.4.2017 v 18:24 Jeff Beatty napsal(a):
>
> True, currently they are all Aurora. We will be moving the localization
>> process to Nightly until such a time as we can complete the work
>> surrounding cross-channel (one Firefox project, not channel-based Firefox
>> projects). The take away is that you may see new strings more often, but
>> you are expected to continue to localize at whatever pace/cadence you feel
>> most comfortable with.
>>
>> Hope that helps,
>> Jeff
>>
>> On Fri, Apr 14, 2017 at 10:18 AM, Michael Wolf <mil...@sorbzilla.de>
>> wrote:
>>
Thanks,
Jeff
other gaps.
On Fri, Apr 14, 2017 at 10:46 AM, Michal Stanke <mst...@mozilla.cz> wrote:
> Hi Jeff.
>
> I have been watching project Dawn for some time as well as the cross
> channel l10n repository plan and I do not see anything bad about them. But
> there are two things I wanted to clarify about the single repository for
> both beta and nightly.
>
> 1. What tools are we going to use to find out, which strings belong to
> beta and need to be done in the cycle?
>
one project. The repository will mark which strings belong to which version
and the tools will include that data.
As to what needs to be done within the cycle, one of the great things about
cross-channel is that there is less pressure on getting things done within
the cycle, since all strings across all branches will be in the same
repo/project.
> 2. What about sign-offs in case we change a string, that is used in
> beta? Are we eventually dropping localizer sign-offs for beta too
> and you (l10n-drivers) will take care of them as in aurora today?
>
We've taken over that process with the policy that we ship all good
updates, big or small, whenever they come in.
Thanks,
Jeff
>
>
> Cheers,
> Michal Stanke
>
> Dne 14.4.2017 v 18:24 Jeff Beatty napsal(a):
>
> True, currently they are all Aurora. We will be moving the localization
>> process to Nightly until such a time as we can complete the work
>> surrounding cross-channel (one Firefox project, not channel-based Firefox
>> projects). The take away is that you may see new strings more often, but
>> you are expected to continue to localize at whatever pace/cadence you feel
>> most comfortable with.
>>
>> Hope that helps,
>> Jeff
>>
>> On Fri, Apr 14, 2017 at 10:18 AM, Michael Wolf <mil...@sorbzilla.de>
>> wrote:
>>
>>> _______________________________________________
>>> dev-l10n mailing list
>>> dev-...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-l10n
>>>
>>>
>>
>>
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
--
>>> dev-l10n mailing list
>>> dev-...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-l10n
>>>
>>>
>>
>>
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
Thanks,
Jeff
Michal Stanke
Apr 14, 2017, 12:59:13 PM4/14/17
to Jeff Beatty, dev-l10n
I know we do not need to sign-off aurora ourselves (I have still done it a
few time, just for the feeling ;). And so you actually ship also updates
that happen in beta? I thought if we change anything in beta, we still need
to click the sign-off button ourselves today.
--
Michal Stanke
few time, just for the feeling ;). And so you actually ship also updates
that happen in beta? I thought if we change anything in beta, we still need
to click the sign-off button ourselves today.
--
Michal Stanke
Jeff Beatty
Apr 14, 2017, 1:00:46 PM4/14/17
to Michal Stanke, dev-l10n
We've taken on the whole sign-off process, Aurora & Beta :-)
Thanks,
Jeff
>>>>> _______________________________________________
>>>>> dev-l10n mailing list
>>>>> dev-...@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-l10n
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> dev-l10n mailing list
>>> dev-...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-l10n
>>>
>>
>>
>>
>> --
>> Thanks,
>> Jeff
>>
>
>
--
>>>>> dev-l10n mailing list
>>>>> dev-...@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-l10n
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> dev-l10n mailing list
>>> dev-...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-l10n
>>>
>>
>>
>>
>> --
>> Thanks,
>> Jeff
>>
>
>
Thanks,
Jeff
Marko Zeka Andrejic
Apr 14, 2017, 3:43:44 PM4/14/17
to
Just to be sure, my community currently doesn't localize Nightly. After Aurora has been discounted, will Nightly automaticaly be enabled on our Pontoon with imported localization from Aurora or should we request for it?
Thanks in advance.
Marko Andrejić, Mozilla Serbia
Thanks in advance.
Marko Andrejić, Mozilla Serbia
Francesco Lodolo
Apr 14, 2017, 3:49:59 PM4/14/17
to Marko Zeka Andrejic, Mozilla l10n Mailing List
Hi,
After Tuesday all projects will be re-enabled and will be pointing to
Nightly, in both Pootle and Pontoon.
The work you've done on aurora until that point will be there, you'll
only see the strings for the new version of Firefox.
This will be done for all locales, no need to request anything.
Francesco
After Tuesday all projects will be re-enabled and will be pointing to
Nightly, in both Pootle and Pontoon.
The work you've done on aurora until that point will be there, you'll
only see the strings for the new version of Firefox.
This will be done for all locales, no need to request anything.
Francesco
Kim Ludvigsen
Apr 14, 2017, 5:24:37 PM4/14/17
to
Den 14-04-2017 kl. 16:48 skrev Francesco Lodolo [:flod]:
>
> This means that you will see more string changes, more frequently. To
> avoid the risk of exposing poor strings to localizers, we plan to
> publish new strings only once or twice a week.
How long before a deadline will there be a string freeze?
>
> This means that you will see more string changes, more frequently. To
> avoid the risk of exposing poor strings to localizers, we plan to
> publish new strings only once or twice a week.
I will not translate several times in a cycle, and I do not like to have
to translate close to a deadline. I prefer to continue doing what I have
been doing for a long time in aurora; that is, taking the new strings
within the first week of a new cycle. Will it be possible to do that in
beta? If so, I will probably go to beta rather than go to nightly.
--
Kind regards
Kim Ludvigsen
Message has been deleted
Message has been deleted
Francesco Lodolo [:flod]
Apr 15, 2017, 12:51:35 AM4/15/17
to dev-...@lists.mozilla.org
Il 15/04/17 00.00, maxxdr...@gmail.com ha scritto:
> I'm curious how this will affect the addon plan for 57. Will Legacy and WebExt Experiments be allowed on Beta now that Aurora is pretty much merged into it? Or will Nightly be the only channel to allow them? which is not stable enough
> As nightly is too unstable for some people and testing addons/themes etc in beta will be very useful.
> WebExtension Experiments is what I was referring to. There is meant to be a pref to allow Legacy extensions in Nightly and (now formerly) in Aurora.
> https://wiki.mozilla.org/Add-ons/Firefox57
> Will xpinstall.signatures.required & xpinstall.whitelist.required will be available in beta then?
Hi,
These are valid questions and concerns, but please let's focus on the
localization impact of this change, since this the mailing list for
localizers.
There will be an official announcement on Monday, with FAQs, we got a
green light to send communication to localizers in advance because of
the drastic change in tools. Those topics will be covered in the
official FAQs.
Francesco
> I'm curious how this will affect the addon plan for 57. Will Legacy and WebExt Experiments be allowed on Beta now that Aurora is pretty much merged into it? Or will Nightly be the only channel to allow them? which is not stable enough
> As nightly is too unstable for some people and testing addons/themes etc in beta will be very useful.
> WebExtension Experiments is what I was referring to. There is meant to be a pref to allow Legacy extensions in Nightly and (now formerly) in Aurora.
> https://wiki.mozilla.org/Add-ons/Firefox57
> Will xpinstall.signatures.required & xpinstall.whitelist.required will be available in beta then?
Hi,
These are valid questions and concerns, but please let's focus on the
localization impact of this change, since this the mailing list for
localizers.
There will be an official announcement on Monday, with FAQs, we got a
green light to send communication to localizers in advance because of
the drastic change in tools. Those topics will be covered in the
official FAQs.
Francesco
Francesco Lodolo [:flod]
Apr 15, 2017, 1:05:41 AM4/15/17
to dev-...@lists.mozilla.org
Il 14/04/17 23.24, Kim Ludvigsen ha scritto:
I think these two questions are relevant
https://github.com/mozilla-l10n/localizer-documentation/blob/master/misc/aurora_faqs.md#q-how-often-will-i-have-new-strings-to-localize
There won't be a string freeze on Nightly, when strings move to Beta
you're going to only have about 4 weeks for translating and testing
before the sign-off deadline.
If you work on Mercurial and decide to translate on Beta, you will also
need to manually port changes to l10n-central (on next merge day, the
content of l10n-central will be moved to mozilla-beta, overwriting the
existing content). If you work on Pontoon, you will need to manually
commit these changes to the Nightly project to avoid losing them.
Things will improve with cross-channel, since you need to commit only to
one repository for all versions. Unfortunately, the next cycle is going
to be a transition phase in that sense, because of the last minute
schedule change.
We are aware that this is going to be a big change for some teams, but
it could also become a chance to involve new contributors (there will be
small batches of strings available every week). It might also be an
occasion to evaluate workflows and tools that have been used efficiently
so far, but don't adapt and scale as well to this new scenario.
Francesco
> How long before a deadline will there be a string freeze?
>
> I will not translate several times in a cycle, and I do not like to
> have to translate close to a deadline. I prefer to continue doing what
> I have been doing for a long time in aurora; that is, taking the new
> strings within the first week of a new cycle. Will it be possible to
> do that in beta? If so, I will probably go to beta rather than go to
> nightly.
Hi Kim,
>
> I will not translate several times in a cycle, and I do not like to
> have to translate close to a deadline. I prefer to continue doing what
> I have been doing for a long time in aurora; that is, taking the new
> strings within the first week of a new cycle. Will it be possible to
> do that in beta? If so, I will probably go to beta rather than go to
> nightly.
I think these two questions are relevant
https://github.com/mozilla-l10n/localizer-documentation/blob/master/misc/aurora_faqs.md#q-how-often-will-i-have-new-strings-to-localize
There won't be a string freeze on Nightly, when strings move to Beta
you're going to only have about 4 weeks for translating and testing
before the sign-off deadline.
If you work on Mercurial and decide to translate on Beta, you will also
need to manually port changes to l10n-central (on next merge day, the
content of l10n-central will be moved to mozilla-beta, overwriting the
existing content). If you work on Pontoon, you will need to manually
commit these changes to the Nightly project to avoid losing them.
Things will improve with cross-channel, since you need to commit only to
one repository for all versions. Unfortunately, the next cycle is going
to be a transition phase in that sense, because of the last minute
schedule change.
We are aware that this is going to be a big change for some teams, but
it could also become a chance to involve new contributors (there will be
small batches of strings available every week). It might also be an
occasion to evaluate workflows and tools that have been used efficiently
so far, but don't adapt and scale as well to this new scenario.
Francesco
Kim Ludvigsen
Apr 15, 2017, 1:55:38 AM4/15/17
to
Den 15-04-2017 kl. 07:05 skrev Francesco Lodolo [:flod]:
>
> If you work on Mercurial and decide to translate on Beta, you will also
> need to manually port changes to l10n-central (on next merge day, the
> content of l10n-central will be moved to mozilla-beta, overwriting the
> existing content).
How do I do that?
>
> If you work on Mercurial and decide to translate on Beta, you will also
> need to manually port changes to l10n-central (on next merge day, the
> content of l10n-central will be moved to mozilla-beta, overwriting the
> existing content).
> We are aware that this is going to be a big change for some teams, but it could
> also become a chance to involve new contributors (there will be small
batches of
> strings available every week)
change of SUMO did.
Francesco Lodolo [:flod]
Apr 15, 2017, 2:19:52 AM4/15/17
to dev-...@lists.mozilla.org
Il 15/04/17 07.55, Kim Ludvigsen ha scritto:
we'll figure out the best way to do it. Changesets should be pulled from
mozilla-beta to l10n-central and merged.
Note that it's not different from localizing now on mozilla-beta with
Mercurial, you need to port your changes into mozilla-aurora on your own
to avoid losing them on merge day.
>
>> We are aware that this is going to be a big change for some teams,
>> but it could
> > also become a chance to involve new contributors (there will be
> small batches of
>> strings available every week)
>
> It could also mean a big chance to lose old contributors; just as the
> change of SUMO did.
We clearly hope that's not the case, even if we understand this change
is going to be harder on some teams than others, especially those not
working on tools like Pootle or Pontoon.
We're here to help as best as we can in this transition.
Francesco
> Den 15-04-2017 kl. 07:05 skrev Francesco Lodolo [:flod]:
>>
>> If you work on Mercurial and decide to translate on Beta, you will also
>> need to manually port changes to l10n-central (on next merge day, the
>> content of l10n-central will be moved to mozilla-beta, overwriting the
>> existing content).
>
> How do I do that?
If you decide to work on beta next cycle, please ping me directly and
>>
>> If you work on Mercurial and decide to translate on Beta, you will also
>> need to manually port changes to l10n-central (on next merge day, the
>> content of l10n-central will be moved to mozilla-beta, overwriting the
>> existing content).
>
> How do I do that?
we'll figure out the best way to do it. Changesets should be pulled from
mozilla-beta to l10n-central and merged.
Note that it's not different from localizing now on mozilla-beta with
Mercurial, you need to port your changes into mozilla-aurora on your own
to avoid losing them on merge day.
>
>> We are aware that this is going to be a big change for some teams,
>> but it could
> > also become a chance to involve new contributors (there will be
> small batches of
>> strings available every week)
>
> It could also mean a big chance to lose old contributors; just as the
> change of SUMO did.
is going to be harder on some teams than others, especially those not
working on tools like Pootle or Pontoon.
We're here to help as best as we can in this transition.
Francesco
Fjoerfoks
Apr 15, 2017, 4:23:28 AM4/15/17
to Francesco Lodolo [:flod], dev-l10n
Hi,
Some of these questions were als answered by Axel in the last bi-weekly
call thithursday.You can view it here:
https://air.mozilla.org/localization-community-bi-monthly-call-2017-04-13/
Not all new strings will be exposed directly to localizers, there will be
some sort of quarantaine.
Wim
Op 15 apr. 2017 8:19 AM schreef "Francesco Lodolo [:flod]" <fl...@lodolo.net
>:
> Il 15/04/17 07.55, Kim Ludvigsen ha scritto:
>
Some of these questions were als answered by Axel in the last bi-weekly
call thithursday.You can view it here:
https://air.mozilla.org/localization-community-bi-monthly-call-2017-04-13/
Not all new strings will be exposed directly to localizers, there will be
some sort of quarantaine.
Wim
Op 15 apr. 2017 8:19 AM schreef "Francesco Lodolo [:flod]" <fl...@lodolo.net
>:
> Il 15/04/17 07.55, Kim Ludvigsen ha scritto:
>
>> Den 15-04-2017 kl. 07:05 skrev Francesco Lodolo [:flod]:
>>
>>>
>>> If you work on Mercurial and decide to translate on Beta, you will also
>>> need to manually port changes to l10n-central (on next merge day, the
>>> content of l10n-central will be moved to mozilla-beta, overwriting the
>>> existing content).
>>>
>>
>> How do I do that?
>>
>>
>>>
>>> If you work on Mercurial and decide to translate on Beta, you will also
>>> need to manually port changes to l10n-central (on next merge day, the
>>> content of l10n-central will be moved to mozilla-beta, overwriting the
>>> existing content).
>>>
>>
>> How do I do that?
>>
> If you decide to work on beta next cycle, please ping me directly and
> we'll figure out the best way to do it. Changesets should be pulled from
> mozilla-beta to l10n-central and merged.
>
> Note that it's not different from localizing now on mozilla-beta with
> Mercurial, you need to port your changes into mozilla-aurora on your own to
> avoid losing them on merge day.
>
>
> we'll figure out the best way to do it. Changesets should be pulled from
> mozilla-beta to l10n-central and merged.
>
> Note that it's not different from localizing now on mozilla-beta with
> Mercurial, you need to port your changes into mozilla-aurora on your own to
> avoid losing them on merge day.
>
>
>> We are aware that this is going to be a big change for some teams, but it
>>> could
>>>
>> > also become a chance to involve new contributors (there will be small
>> batches of
>>
>>> strings available every week)
>>>
>>
>> It could also mean a big chance to lose old contributors; just as the
>> change of SUMO did.
>>
>>> could
>>>
>> > also become a chance to involve new contributors (there will be small
>> batches of
>>
>>> strings available every week)
>>>
>>
>> It could also mean a big chance to lose old contributors; just as the
>> change of SUMO did.
>>
> We clearly hope that's not the case, even if we understand this change is
> going to be harder on some teams than others, especially those not working
> on tools like Pootle or Pontoon.
>
> We're here to help as best as we can in this transition.
>
> Francesco
>
>
>
>
>
> going to be harder on some teams than others, especially those not working
> on tools like Pootle or Pontoon.
>
> We're here to help as best as we can in this transition.
>
> Francesco
>
>
>
>
>
Francesco Lodolo [:flod]
Apr 15, 2017, 6:07:41 AM4/15/17
to dev-l10n
Il 15/04/17 10.23, Fjoerfoks ha scritto:
last call (thanks Théo for taking them)
https://public.etherpad-mozilla.org/p/l10n-community-13-04-2017
If anybody is interested in the details, they're available here
https://github.com/mozilla-l10n/localizer-documentation/blob/master/misc/aurora_faqs.md#q-i-work-directly-on-mercurial-is-something-going-to-change-for-me
Francesco
> Not all new strings will be exposed directly to localizers, there will
> be some sort of quarantaine.
Thanks Wim, if someone is interested there are also meeting notes for
> be some sort of quarantaine.
last call (thanks Théo for taking them)
https://public.etherpad-mozilla.org/p/l10n-community-13-04-2017
If anybody is interested in the details, they're available here
https://github.com/mozilla-l10n/localizer-documentation/blob/master/misc/aurora_faqs.md#q-i-work-directly-on-mercurial-is-something-going-to-change-for-me
Francesco
Axel Hecht
Apr 15, 2017, 11:19:29 AM4/15/17
to
Am 14.04.17 um 23:24 schrieb Kim Ludvigsen:
This is a reply for more folks than just Kim. We've heard similar
stories in the workshops of the past year or two, so I'd like to give a
more general perspective...
Truth be told, I expect that Firefox will become a suite of localizable
features shipping on different schedules. Test pilot and other system
addons are just the start, and we'll have more of that. I don't think
that we'll be able to tell you N weeks in advance if you've fully
translated Firefox 60.
What we can do is trying to make that as seamless as possible, but we
can't keep mozilla from shipping things as part of Firefox that just had
2-3 weeks of exposure to localization.
We'll expose strings in a more continuous fashion, frequently and
incrementally, to localizers. At the same time, we're trying to get
fixes from localizers out to end-users in a timely fashion. The idea is
to reward improvements to a localization with actually shipping it to users.
What we're trying to achieve is to also take away the pressure of
timelines and calendars, and make localization of Firefox more fun
again. For most of our community members, this will actually work out
this way, while for some it might not be the best fit. I'm saying "most
of our community members" because we did talk to many of you over the
past year about patterns of localization and contribution, and for many
the rapid release cycle didn't work out great. It took away the hobby of
translating Firefox for 5 weeks out of 6, and that's just awful.
At the same time, the rapid release cycle doesn't work well for those of
you that are driven by the sense of achievement, or that want to dive
deep into translation for a period of time. We just didn't offer the
achievement of localizing Firefox 4, and then have celebrate that
release, whether it's press or websites or parties or just a cup of tea
on Sunday afternoon. We just don't expose a meaningful bucket of 1000
words to dive into over a weekend. If you're in this group, I invite you
to reach out to us, and see if we can find ways to substitute these
motivation factors with.
To close with a suggestion. Set a release cycle for yourself. Release
something to yourself, and to your community every two or three weeks.
Build out ways to create an achievement on those. If it's the cup of tea
on Sunday afternoon or some community post or whatever works for you.
The idea here is this: The release cadence that you can ignore the
easiest is the 6-8 weeks where we bump the major version number. If your
heart ticks on that beat, you'll be hurt, but if it beats more
frequently, you won't be hurt, and hopefully you can give that frequency
purpose. And with x-channel, finding that purpose will be at least
possible, which is frankly impossible with the current way of localizing
the rapid release process.
There's an opportunity to find a new compromise between yourself and the
way we ship Firefox.
In closing, this is a response addressing concerns we heard from a few
of you, and I hope that Kim can make something useful out of this, too.
Hope that helps
Axel
stories in the workshops of the past year or two, so I'd like to give a
more general perspective...
Truth be told, I expect that Firefox will become a suite of localizable
features shipping on different schedules. Test pilot and other system
addons are just the start, and we'll have more of that. I don't think
that we'll be able to tell you N weeks in advance if you've fully
translated Firefox 60.
What we can do is trying to make that as seamless as possible, but we
can't keep mozilla from shipping things as part of Firefox that just had
2-3 weeks of exposure to localization.
We'll expose strings in a more continuous fashion, frequently and
incrementally, to localizers. At the same time, we're trying to get
fixes from localizers out to end-users in a timely fashion. The idea is
to reward improvements to a localization with actually shipping it to users.
What we're trying to achieve is to also take away the pressure of
timelines and calendars, and make localization of Firefox more fun
again. For most of our community members, this will actually work out
this way, while for some it might not be the best fit. I'm saying "most
of our community members" because we did talk to many of you over the
past year about patterns of localization and contribution, and for many
the rapid release cycle didn't work out great. It took away the hobby of
translating Firefox for 5 weeks out of 6, and that's just awful.
At the same time, the rapid release cycle doesn't work well for those of
you that are driven by the sense of achievement, or that want to dive
deep into translation for a period of time. We just didn't offer the
achievement of localizing Firefox 4, and then have celebrate that
release, whether it's press or websites or parties or just a cup of tea
on Sunday afternoon. We just don't expose a meaningful bucket of 1000
words to dive into over a weekend. If you're in this group, I invite you
to reach out to us, and see if we can find ways to substitute these
motivation factors with.
To close with a suggestion. Set a release cycle for yourself. Release
something to yourself, and to your community every two or three weeks.
Build out ways to create an achievement on those. If it's the cup of tea
on Sunday afternoon or some community post or whatever works for you.
The idea here is this: The release cadence that you can ignore the
easiest is the 6-8 weeks where we bump the major version number. If your
heart ticks on that beat, you'll be hurt, but if it beats more
frequently, you won't be hurt, and hopefully you can give that frequency
purpose. And with x-channel, finding that purpose will be at least
possible, which is frankly impossible with the current way of localizing
the rapid release process.
There's an opportunity to find a new compromise between yourself and the
way we ship Firefox.
In closing, this is a response addressing concerns we heard from a few
of you, and I hope that Kim can make something useful out of this, too.
Hope that helps
Axel
Axel Hecht
Apr 15, 2017, 11:28:16 AM4/15/17
to
Am 14.04.17 um 18:46 schrieb Michal Stanke:
from thinking in terms of 6-8 weeks cycles.
More to your question, there are broadly two buckets:
Those locales without missing strings: You don't have missing strings,
and beta will continue to be string frozen, so if you're done at some
point in a window of a couple of weeks, you're done with beta.
Those locales with missing strings: Whether a string misses on beta or
not is likely going to be less of an issue than if that string's in
important pieces of the UI or not.
That said, we'll have stats on the dashboard for central and beta, but I
don't think that the practical impact of them on what localizers do is
high right now, and wouldn't be high in the future. And I also hope that
we can get away from localizing system addons outside of Firefox, so the
concept of "cycle" will loose value on the content in l10n-central.
Axel
> Hi Jeff.
>
> I have been watching project Dawn for some time as well as the cross
> channel l10n repository plan and I do not see anything bad about them.
> But there are two things I wanted to clarify about the single repository
> for both beta and nightly.
>
> 1. What tools are we going to use to find out, which strings belong to
> beta and need to be done in the cycle?
As I've mentioned in my other reply, I think that we'll need to get away
>
> I have been watching project Dawn for some time as well as the cross
> channel l10n repository plan and I do not see anything bad about them.
> But there are two things I wanted to clarify about the single repository
> for both beta and nightly.
>
> 1. What tools are we going to use to find out, which strings belong to
> beta and need to be done in the cycle?
from thinking in terms of 6-8 weeks cycles.
More to your question, there are broadly two buckets:
Those locales without missing strings: You don't have missing strings,
and beta will continue to be string frozen, so if you're done at some
point in a window of a couple of weeks, you're done with beta.
Those locales with missing strings: Whether a string misses on beta or
not is likely going to be less of an issue than if that string's in
important pieces of the UI or not.
That said, we'll have stats on the dashboard for central and beta, but I
don't think that the practical impact of them on what localizers do is
high right now, and wouldn't be high in the future. And I also hope that
we can get away from localizing system addons outside of Firefox, so the
concept of "cycle" will loose value on the content in l10n-central.
Axel
Ricardo Palomares Martínez
Apr 15, 2017, 3:39:22 PM4/15/17
to
El 14/04/17 a las 16:48, Francesco Lodolo [:flod] escribió:
change, but a global Mozilla movement.
As you know, I keep localizing in Central, and directly on Mercurial.
I have some questions that I haven't seen covered in the FAQ. Some of
them may apply to folks using Pootle and Pontoon, too:
1. Stating the obvious, I understand that starting next week, I'll
have to uplift contents from l10n-central to l10n-mozilla-beta instead
of l10n-mozilla-aurora. Am I right? In that case, the uplifting doc
[1] will have to be reviewed.
2. When the channel shift deadline is approaching (and I mean hours
before, not days), more often than not a bunch of strings are dumped
in Central and then uplifted to Aurora. I guess this is a rush to
check in features "before the channel gates open for a brief time in
the 6-week cycle". As some developers fail to check in time by a
matter of minutes and land it in central just after the shift, I've
found myself many times updating en-US repos, translating changes from
mozilla-aurora and dumping them to l10n-central before uplifting the
repos changes, just to have Aurora in shape. Now, I can do the same
with Beta, but how will localizers using Pootle/Pontoon manage to do
it? Or will you prevent those last minute changes to land?
3. Aurora was supposed to be for stabilizing features, not adding new,
so string changes in that channel were going to be very rare. But we
all know that has not been the case: string-freeze breaks have been
the norm (I doubt there has been a single cycle where no strings have
got in Aurora out of the uplift mass landing). The question is: will
this keep happening in Beta? And if so, how will it be dealt with in
Pootle/Pontoon?
TIA
[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Uplifting
--
Proyecto NAVE (Mozilla es-ES Localization Team)
Mozilla Hispano Community
> Hi localizers,
> A significant change is going to happen to Mozilla’s release model,
> and is going to happen quickly, in just a few days.
>
> The Aurora branch will be discontinued on April 18 (next Tuesday).
Interesting news, Francesco. I understand this is not a L10n-driven
> A significant change is going to happen to Mozilla’s release model,
> and is going to happen quickly, in just a few days.
>
> The Aurora branch will be discontinued on April 18 (next Tuesday).
change, but a global Mozilla movement.
As you know, I keep localizing in Central, and directly on Mercurial.
I have some questions that I haven't seen covered in the FAQ. Some of
them may apply to folks using Pootle and Pontoon, too:
1. Stating the obvious, I understand that starting next week, I'll
have to uplift contents from l10n-central to l10n-mozilla-beta instead
of l10n-mozilla-aurora. Am I right? In that case, the uplifting doc
[1] will have to be reviewed.
2. When the channel shift deadline is approaching (and I mean hours
before, not days), more often than not a bunch of strings are dumped
in Central and then uplifted to Aurora. I guess this is a rush to
check in features "before the channel gates open for a brief time in
the 6-week cycle". As some developers fail to check in time by a
matter of minutes and land it in central just after the shift, I've
found myself many times updating en-US repos, translating changes from
mozilla-aurora and dumping them to l10n-central before uplifting the
repos changes, just to have Aurora in shape. Now, I can do the same
with Beta, but how will localizers using Pootle/Pontoon manage to do
it? Or will you prevent those last minute changes to land?
3. Aurora was supposed to be for stabilizing features, not adding new,
so string changes in that channel were going to be very rare. But we
all know that has not been the case: string-freeze breaks have been
the norm (I doubt there has been a single cycle where no strings have
got in Aurora out of the uplift mass landing). The question is: will
this keep happening in Beta? And if so, how will it be dealt with in
Pootle/Pontoon?
TIA
[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Uplifting
--
Proyecto NAVE (Mozilla es-ES Localization Team)
Mozilla Hispano Community
Axel Hecht
Apr 15, 2017, 5:29:10 PM4/15/17
to
Am 15.04.17 um 21:39 schrieb Ricardo Palomares Martínez:
the questions you ask all kind-of have the same answer: this is not
going to work if we don't have cross-channel. The interesting date for
x-channel is the merge to beta, so I have a few more weeks to stand that
up completely. In the worst case, I might miss a cycle, in which case we
need to deal with this for a single cycle. But x-channel just needs to
happen. How that's the answer to your questions below.
> 1. Stating the obvious, I understand that starting next week, I'll
> have to uplift contents from l10n-central to l10n-mozilla-beta instead
> of l10n-mozilla-aurora. Am I right? In that case, the uplifting doc
> [1] will have to be reviewed.
With x-channel, there's only a single repository, and thus no uplifts
required.
> 2. When the channel shift deadline is approaching (and I mean hours
> before, not days), more often than not a bunch of strings are dumped
> in Central and then uplifted to Aurora. I guess this is a rush to
> check in features "before the channel gates open for a brief time in
> the 6-week cycle". As some developers fail to check in time by a
> matter of minutes and land it in central just after the shift, I've
> found myself many times updating en-US repos, translating changes from
> mozilla-aurora and dumping them to l10n-central before uplifting the
> repos changes, just to have Aurora in shape. Now, I can do the same
> with Beta, but how will localizers using Pootle/Pontoon manage to do
> it? Or will you prevent those last minute changes to land?
Stability of Nightly needs to go up, and there are a ton of projects
already in action to make that happen. There will be more details on
this in the more general communication next week.
That said, with x-channel, you will have central as a superset of the
strings on beta, guaranteed. So you can just continue to work on central
and the strings will be good for beta, and we'll use them on beta. So
the strings that land around merge day will just be new strings, and the
fact that some are used on beta and some are only used on central will
only be interesting from the perspective of "can I test these strings on
beta?".
Fixing those will not come with an immediate time pressure, too. As I
mentioned in my other lengthy reply, shipping strings every other weeks
from the localizer point-of-view will be perfectly fine.
> 3. Aurora was supposed to be for stabilizing features, not adding new,
> so string changes in that channel were going to be very rare. But we
> all know that has not been the case: string-freeze breaks have been
> the norm (I doubt there has been a single cycle where no strings have
> got in Aurora out of the uplift mass landing). The question is: will
> this keep happening in Beta? And if so, how will it be dealt with in
> Pootle/Pontoon?
Right, string freeze isn't that we can't possibly change the strings on
a release, but that we know that if we do, we might not get
localizations of those strings. The approval process for patches that
require strings is "is this string in English better than not taking
this patch". Hard judgement, and sometimes we can't explain all the
reasons, but that's basically the deal.
Again, with x-channel, you could find yourself in the situation that you
already localized the uplifted string for central, it's just that now
also en-US starts using it on a more stable channel. In that case, the
localization ecosystem won't even notice.
If this is a string that's only needed on the stable channel, you'll
find that string as a new string on the x-channel repo, you'll localize
it and land in l10n-central via pontoon, pootle or vi, and then the
stable channel will just pick it up. From a localizer perspective, this
is just business as usual. (Side note, we had these strings for API
deprecation notices and such in the past.)
Summing up, yes, you're asking the right questions, and it so happens
that our x-channel work is the best answer for all of them.
Axel
> El 14/04/17 a las 16:48, Francesco Lodolo [:flod] escribió:
>> Hi localizers,
>> A significant change is going to happen to Mozilla’s release model,
>> and is going to happen quickly, in just a few days.
>>
>> The Aurora branch will be discontinued on April 18 (next Tuesday).
>
>
> Interesting news, Francesco. I understand this is not a L10n-driven
> change, but a global Mozilla movement.
>
> As you know, I keep localizing in Central, and directly on Mercurial.
> I have some questions that I haven't seen covered in the FAQ. Some of
> them may apply to folks using Pootle and Pontoon, too:
Hi Ricardo,
>> Hi localizers,
>> A significant change is going to happen to Mozilla’s release model,
>> and is going to happen quickly, in just a few days.
>>
>> The Aurora branch will be discontinued on April 18 (next Tuesday).
>
>
> Interesting news, Francesco. I understand this is not a L10n-driven
> change, but a global Mozilla movement.
>
> As you know, I keep localizing in Central, and directly on Mercurial.
> I have some questions that I haven't seen covered in the FAQ. Some of
> them may apply to folks using Pootle and Pontoon, too:
the questions you ask all kind-of have the same answer: this is not
going to work if we don't have cross-channel. The interesting date for
x-channel is the merge to beta, so I have a few more weeks to stand that
up completely. In the worst case, I might miss a cycle, in which case we
need to deal with this for a single cycle. But x-channel just needs to
happen. How that's the answer to your questions below.
> 1. Stating the obvious, I understand that starting next week, I'll
> have to uplift contents from l10n-central to l10n-mozilla-beta instead
> of l10n-mozilla-aurora. Am I right? In that case, the uplifting doc
> [1] will have to be reviewed.
required.
> 2. When the channel shift deadline is approaching (and I mean hours
> before, not days), more often than not a bunch of strings are dumped
> in Central and then uplifted to Aurora. I guess this is a rush to
> check in features "before the channel gates open for a brief time in
> the 6-week cycle". As some developers fail to check in time by a
> matter of minutes and land it in central just after the shift, I've
> found myself many times updating en-US repos, translating changes from
> mozilla-aurora and dumping them to l10n-central before uplifting the
> repos changes, just to have Aurora in shape. Now, I can do the same
> with Beta, but how will localizers using Pootle/Pontoon manage to do
> it? Or will you prevent those last minute changes to land?
already in action to make that happen. There will be more details on
this in the more general communication next week.
That said, with x-channel, you will have central as a superset of the
strings on beta, guaranteed. So you can just continue to work on central
and the strings will be good for beta, and we'll use them on beta. So
the strings that land around merge day will just be new strings, and the
fact that some are used on beta and some are only used on central will
only be interesting from the perspective of "can I test these strings on
beta?".
Fixing those will not come with an immediate time pressure, too. As I
mentioned in my other lengthy reply, shipping strings every other weeks
from the localizer point-of-view will be perfectly fine.
> 3. Aurora was supposed to be for stabilizing features, not adding new,
> so string changes in that channel were going to be very rare. But we
> all know that has not been the case: string-freeze breaks have been
> the norm (I doubt there has been a single cycle where no strings have
> got in Aurora out of the uplift mass landing). The question is: will
> this keep happening in Beta? And if so, how will it be dealt with in
> Pootle/Pontoon?
a release, but that we know that if we do, we might not get
localizations of those strings. The approval process for patches that
require strings is "is this string in English better than not taking
this patch". Hard judgement, and sometimes we can't explain all the
reasons, but that's basically the deal.
Again, with x-channel, you could find yourself in the situation that you
already localized the uplifted string for central, it's just that now
also en-US starts using it on a more stable channel. In that case, the
localization ecosystem won't even notice.
If this is a string that's only needed on the stable channel, you'll
find that string as a new string on the x-channel repo, you'll localize
it and land in l10n-central via pontoon, pootle or vi, and then the
stable channel will just pick it up. From a localizer perspective, this
is just business as usual. (Side note, we had these strings for API
deprecation notices and such in the past.)
Summing up, yes, you're asking the right questions, and it so happens
that our x-channel work is the best answer for all of them.
Axel
Francesco Lodolo [:flod]
Apr 16, 2017, 2:00:27 AM4/16/17
to dev-...@lists.mozilla.org
> 1. Stating the obvious, I understand that starting next week, I'll
> have to uplift contents from l10n-central to l10n-mozilla-beta instead
> of l10n-mozilla-aurora. Am I right? In that case, the uplifting doc
> [1] will have to be reviewed.
Axel already explained that we won't need uplifts to mozilla-beta with
> have to uplift contents from l10n-central to l10n-mozilla-beta instead
> of l10n-mozilla-aurora. Am I right? In that case, the uplifting doc
> [1] will have to be reviewed.
cross-channel. That document and procedure will become completely
unnecessary.
I've just sent an email to the handful of localizers working on
l10n-central (before seeing this thread), but I'll explain here too.
On Tuesday l10n content for mozilla-aurora will be migrated as usual to
mozilla-beta (by l10n-drivers), as part of merge day migrations.
Localizers working on l10n-central (eo, es-ES, fr, it, pl, ru) must not
uplift their updates from l10n-central to mozilla-aurora, because that
content will be used to ship security updates to existing aurora builds
(still 54), and it's important to keep the strings as they are.
> 2. When the channel shift deadline is approaching (and I mean hours
> before, not days), more often than not a bunch of strings are dumped
> in Central and then uplifted to Aurora. I guess this is a rush to
> check in features "before the channel gates open for a brief time in
> the 6-week cycle". As some developers fail to check in time by a
> matter of minutes and land it in central just after the shift, I've
> found myself many times updating en-US repos, translating changes from
> mozilla-aurora and dumping them to l10n-central before uplifting the
> repos changes, just to have Aurora in shape. Now, I can do the same
> with Beta, but how will localizers using Pootle/Pontoon manage to do
> it? Or will you prevent those last minute changes to land?
that won't be a problem. If we fail to be ready before that deadline, we
have contingency plans.
I also hope that, being 55 a double cycle for Nightly on central, we'll
have a less confusing week-end before that merge day.
> 3. Aurora was supposed to be for stabilizing features, not adding new,
> so string changes in that channel were going to be very rare. But we
> all know that has not been the case: string-freeze breaks have been
> the norm (I doubt there has been a single cycle where no strings have
> got in Aurora out of the uplift mass landing). The question is: will
> this keep happening in Beta? And if so, how will it be dealt with in
> Pootle/Pontoon?
are requests to uplift developer error messages, and we normally ask for
an aurora-only patch that hard-code these strings, to minimize the
churn. That will become less complicated with cross-channel.
The whole organization's goal is that requests to uplift from central to
beta won't be as frequent as they were on central->aurora. By removing
aurora you're cutting 6-8 weeks from the time needed for a piece of code
to reach the release audience, there should be less need to take shortcuts.
Francesco
Kim Ludvigsen
Apr 16, 2017, 6:31:12 AM4/16/17
to
Den 15-04-2017 kl. 08:19 Francesco Lodolo [:flod] wrote:
> If you decide to work on beta next cycle, please ping me directly and
> we'll figure out the best way to do it.
Looking past the next cycle, how will it work with deadlines and new
> If you decide to work on beta next cycle, please ping me directly and
> we'll figure out the best way to do it.
strings on beta when x-channel is up and running? I don't think we ever
got a clear answer to that when talking about the x-channel at the
workshops. Will there be a certain period before the next merge day
without new strings, i.e. a string freeze? And if so, how long will it be?
Den 15-04-2017 kl. 17:19 Axel Hecht wrote:
>> What we're trying to achieve is to also take away the pressure of
>> timelines and calendars, and make localization of Firefox more fun
>> again.
continued flow of new strings and no clear deadline and a string freeze.
It would be like in the old days when the string freeze were only there
in name. I do not want to go back to something similar.
Also, for me it is not fun (although, compared to the old days ...). I
translate because I mostly agree with Mozilla's charter and I want
Danish people to be able to use the programs in Danish. For me it is
work, something that has to be done; more like a duty.
Francesco Lodolo
Apr 21, 2017, 2:53:21 AM4/21/17
to Kim Ludvigsen, Mozilla l10n Mailing List
Sorry, this fell into the cracks of Easter holidays first, and traveling later.
2017-04-16 18:30 GMT+08:00 Kim Ludvigsen <lud...@kimludvigsen.dk>:
> Looking past the next cycle, how will it work with deadlines and new strings
> on beta when x-channel is up and running? I don't think we ever got a clear
> answer to that when talking about the x-channel at the workshops. Will there
> be a certain period before the next merge day without new strings, i.e. a
> string freeze? And if so, how long will it be?
With cross-channel the repository will never stop receiving new
strings (from Nightly). So, to answer your question, there won't be a
period of string freeze in the repository that could be used to
translate Beta.
If you decide to localize the last week of Nightly, you will be
basically translating the content for Beta, similarly to what you were
doing on Aurora.
Initially the deadline for sign-offs on beta will remain the same,
with two significative areas that could change:
* We need to rethink what sign-offs mean in a cross-channel world.
Right now we sign-off an application and a version (firefox53), that
will probably change.
* We want to ship more updates on beta (beyond the current deadline)
and in dot releases. That requires an agreement with Release
Management, product owners, and an evaluation of risks.
Francesco
2017-04-16 18:30 GMT+08:00 Kim Ludvigsen <lud...@kimludvigsen.dk>:
> Looking past the next cycle, how will it work with deadlines and new strings
> on beta when x-channel is up and running? I don't think we ever got a clear
> answer to that when talking about the x-channel at the workshops. Will there
> be a certain period before the next merge day without new strings, i.e. a
> string freeze? And if so, how long will it be?
strings (from Nightly). So, to answer your question, there won't be a
period of string freeze in the repository that could be used to
translate Beta.
If you decide to localize the last week of Nightly, you will be
basically translating the content for Beta, similarly to what you were
doing on Aurora.
Initially the deadline for sign-offs on beta will remain the same,
with two significative areas that could change:
* We need to rethink what sign-offs mean in a cross-channel world.
Right now we sign-off an application and a version (firefox53), that
will probably change.
* We want to ship more updates on beta (beyond the current deadline)
and in dot releases. That requires an agreement with Release
Management, product owners, and an evaluation of risks.
Francesco
Francesco Lodolo
Apr 22, 2017, 5:43:21 AM4/22/17
to Mozilla l10n Mailing List
> If you decide to localize the last week of Nightly, you will be
> basically translating the content for Beta, similarly to what you were
> doing on Aurora.
Answering to myself with a less jet-lagged brain, to make an important
> basically translating the content for Beta, similarly to what you were
> doing on Aurora.
point clear: I'm not suggesting to translate Beta as a good and
sustainable workflow.
We are able to ship better quality products on Beta because we have
people testing on Nightly. We should aim to do the same for our
localizations: localize early, get people to test as early as
possible, use Beta build only to get feedback from a larger audience
and do minor updates.
Francesco
0 new messages